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Abstract 

i* models are inherently sequence agnostic. There is an immediate need to bridge 
the gap between such a sequence agnostic model and an industry implemented 
process modelling standard like Business Process Modelling Notation (BPMN). 
This work is an attempt to build State Transition Models from i* models. In 
this paper, we first spell out the Naive Algorithm formally, which is on the lines 
of Formal Tropos [T] . We demonstrate how the growth of the State Transition 
Model Space can be mapped to the problem of finding the number of possible 
paths between the Least Upper Bound (LUB) and the Greatest Lower Bound 
(GLB) of a fc-dimensional hypercube Lattice structure. We formally present the 
mathematics for doing a quantitative analysis of the space growth. The Naive 
Algorithm has its main drawback in the hyperexponential explosion caused in 
the State Transition Model space. This is identified and the Semantic Implosion 
Algorithm is proposed which exploits the temporal information embedded within 
the i* model of an enterprise to reduce the rate of growth of the State Transition 
Model space. A comparative quantitative analysis between the two approaches 
concludes the superiority of the Semantic Implosion Algorithm. 
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1. Introduction 


The use of models for software development has become a very standard 
software engineering practise. The advantages of using modelling notations to 
obtain the working view of a system or software, before actually coding it, is 
well-known. The most prominent benefits of modelling a system is to identify 
risks of failure before the coding of the system / software actually begins. Also, 
the use of standard modelling notations like UML helps in automated generation 
of code snippets. 

A system or enterprise is modelled during the design phase of the develop¬ 
ment life cycle, only after the requirement specifications have been frozen by the 
consumer. Requirements Engineering helps in maintaining and documenting the 
user requirements. Requirement specifications are finalized only after multiple 
communications between the designer and the consumer. It is always beneficial 
to both the consumer and the designer if a working model of the system / enter¬ 
prise can be obtained during the requirement analysis phase of development, i* 
models were proposed keeping this in mind. The i* model provides an abstract 
sequence-agnostic view of the system to the consumer. In other words, it identi¬ 
fies actors and how they interact with each other. The i* model does not specify 
an activity work-flow or data-flow to the consumer. Temporal information is 
not specified anywhere within an i* model. This graphical representation of the 
system acts as a dashboard to the consumer where he can specify changes and 
be sure that the developer is in sync with what the consumer requires. 

Merely developing a formal modelling tool for requirement analysis only does 
not help the software engineering community much, i* models can have a huge 
impact on the development life cycle of systems / enterprises if we can map 
them to activity diagrams, and work-flow and data-flow models. Sequential 
or temporal characteristics are an inherent property of any standard business 
process model like BPMN or Petri-Nets. Without any control flow informa¬ 
tion, i* models prove to be futile. Again, since i* models are supposed to be 
sequence-agnostic, proposing modifications over i* models to incorporate tem- 
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poral information, changes the very semantics and purpose of the i* modelling 
notation.The need of the hour is, thus, to bridge this gap between a sequence- 
agnostic requirements analysis model and a control-flow specific business process 
model. This paper is a conscious effort towards bridging this gap. 

The most obvious solution to this problem is using the brute-force method. 
Fuxman introduced the concept of actor instances and how dependencies, as¬ 
sertions, possibilities, and invariants can exist in either of three states - Not 
Created, Created but Not Fulfilled, and Fulfilled [T]. The Naive Algorithm ex¬ 
tends this concept to Goals, Tasks, Resources, and Dependencies existing within 
an i* model. It assumes that every model element goes through the above three 
states and makes two state transitions to reach the Fulfilled state from the Not 
Created state. Using this brute-force method to generate all possible state tran¬ 
sition models corresponding to an i* model, results in an explosion within the 
state transition model space. This is identified in the following section. It is 
interesting to observe that, although an i* model is sequence agnostic, yet there 
exists some features or modelling constructs of the i* model that provide some 
temporal insight into the underlying system / enterprise. For instance, every 
dependency has a cause-effect property in the sense that it is only when a de- 
pendee satisfies or fulfils a requirement of the depender does the dependency 
become satisfied. The Semantic Implosion Algorithm identifies these untapped 
temporal characteristics and tries to contain the rate of growth of the state 
transition model space corresponding to an i* model. Simulation results reveal 
that the Semantic Implosion Algorithm indeed outperforms the Naive algorithm 
and provides a drastic improvement over the brute-force method. 

The rest of the paper is structured as follows. Section [^provides a review on 
existing techniques for transforming models. This section identifies that i* mod¬ 
els have not beeen transformed to sequential models so far. The next section 
(Section]^ details out the Naive Algorithm and the State Implosion Algorithm. 
The drawbacks of the Naive Algorithm are identified and the Semantic Implo¬ 
sion Algorithm is proposed as a solution to these drawbacks. Section [^performs 
a detailed simulation where both the algorithms are applied to the same classes 
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of i* models and their behaviour are observed, compared and contrasted. Fi¬ 
nally, section concludes the paper. 

2. State-of-the-Art 

Sendall and Kozaczynski had already identihed Model Transformation as 
the central driving force behind Model-Driven Software Development [2] . Model 
Transformation represents the daunting challenge of converting higher-level ab¬ 
straction models to platform-specific implementation models that may be used 
for automated code generation. Performing a model transformation requires a 
clear understanding of the abstract syntax and semantics of both the source and 
target. 

Most Model-Driven Engineering practises offer a black box view of the trans¬ 
formation logic making it difficult to observe the operational semantics of a 
transformation. Most strategies work with lower levels of abstraction and en¬ 
counter several limitations. In [3], the authors propose a Domain Specific Lan¬ 
guage over Colored Petri-Nets - called Transformation Nets - that provides a 
high level of model transformation abstraction. An integrated view of places, 
transitions, and tokens, provide a clear insight into the previously hidden oper¬ 
ational semantics. 

Model transformation plays a vital role in bridging the gap between non- 
successive phases of the software development life cycle. [4] presents one such 
attempt to bridge the gap between system designers and system analysts. A 
model generated by the designer is transformed to a model suitable for con¬ 
ducting analysis, the outcome of the analysis is mapped back into the design 
domain. The authors work with UML2Alloy - a tool that takes a UML Class 
diagram augmented with OCL constraints and converts it into the Alloy formal 
representation. Design inconsistency analysis is done on the Alloy representa¬ 
tion. Alloy creates counter examples for any such inconsistency and converts it 
back into a UML Object diagram. This paper tries to do model transformation 
for bridging the gap between the Requirements phase and the Design phase of 
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the development life cycle. 

Creating a wide array of formal models for enhancing the system engineer¬ 
ing process, proves to have time and cost overheads. Kerzhner and Paredis use 
model transformations to achieve this objective, overcoming the overheads, in 
[S]. Formal models are used to specify the structures of varying design alter¬ 
natives and design requirements, along with experiments that conform the two. 
These models are represented using the Object Management Group’s Systems 
Modelling Language (OMG SysMLTM). Model transformation is then used to 
transform design structures into analysis models by combining the knowledge 
of reusable model libraries. Analysis models are transformed into executable 
simulations which help in identifying possible system alternatives. Model trans¬ 
formation plays a vital role in this work. 

Mussbacher, et al, have performed a detailed comparison of six different 
modelling approaches in [B]. The modelling approaches that were assessed 
include Aspect-oriented User Requirements Notation (AoURN) [7], Activity 
Theory {AT) [8], The Cloud Component Approach {CCA), Model Driven Ser¬ 
vice Engineering {MDSE) [9], Object-oriented Software Product Line Modelling 
{00-SPL) [TO], and Reusable Aspect Models {RAM) [TT1[T^. The comparison 
criteria werre grouped into two broad categories - Modelling Dimensions and 
Key Concepts. Modelling dimensions include properties like Phase, Notation, 
and Units of Encapsulation. Key concepts, on the other hand, provide an in¬ 
sight into parameters like Paradigm, Modularity, Composability, Traceability 
and Trade-off Analysis. Of these six approaches, AoURN [3 [13] and 00-SPL 
[To] are of interest to this work, as both these approaches are applicable in the 
Early and Late Requirements phases of software development, the i* modelling 
notation belongs to this approach. In fact, AoURN is based on the ITU-T Z.151 
[M] standard that uses Goal-oriented Requirements Language (GRL), that is 
based on i* modelling. AoURN is machine analysable and can perform sce¬ 
nario regression tests, goal-model evaluation, and ttrade-off analysis. Unlike 
the other modelling approaches, AoURN provides structural, behavioural, and 
intentional views, along with generic support for qualities and non-functional 
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properties. It is purely graphical in nature. 

The importance of i* modelling in Requirements Engineering has been well 
established in the last couple of years. Model transformations help in reducing 
the time and cost overheads associated with developing formal models for all 
possible design strategies across different architectures. There exists solutions 
to transform design models into execution sequences and perform various types 
of analyses. However, no work has been done so far on transforming requirement 
specification models to design models. Bridging this gap will help in identifying 
risks and failures during the Requirement Specihcation and Analysis phase of 
software development itself. Also, modern enterprises must ensure that they 
conform to a well-defined set of compliance rules involving government laws 
and regulations. Compliance checking deals with ensuring that an enterprise 
is system compliant. Although compliance rules can be defined as temporal 
properties on the system, compliance conformance cannot be verified with the 
i* model as it is typically sequence agnostic. In order to perform any type of 
model checking, we must first transform such a sequence-agnostic i* model into 
some form of state transition model that provides an insight into the possible 
sequence of activities within the enterprise. However, since it is an intuitive ex¬ 
traction of state transition models from an i* model, we might not be restricted 
to one particular unique solution. Rather, such a model transformation will be 
a one-to-many mapping. This work takes a leap in the efforts to bridge the gap 
between requirement models and design models. Two algorithms are presented 
and discussed that achieve this. A quantitative analysis is also performed be¬ 
tween the two and the superiority of the Semantic Implosion Algorithm over 
the Naive Algorithm is established. 

3. Developing State Transition Models from an i* model 

The primary aim of this research is to analyze an i* model and develop all 
possible state transition models that can be derived from the given i* model. 
The challenge as well as motivation behind this work lies in the fact that i* 
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models are sequence agnostic. However, without identifying a sequence of oper¬ 
ations within the enterprise, it becomes very difficult to check and verify tem¬ 
poral properties and compliance rules within the system. Again, it is to be kept 
in mind that since an i* model is sequence agnostic, we cannot deterministically 
establish one single state transition model that corresponds to a given i* model. 
The output of this work will generate a set of state transition models, each of 
which satisfy the specification of the i* model. Once we obtain this valid set 
of plausible state transition models, we can apply some user dehned enterprise 
specific compliance rules that fine tunes this set of probable state models. This 
final set of pruned state transition models can then be reverted back to the 
Enterprise owner in order to verify the requirements. 

In this work we are considering the more detailed strategic relationship (SR) 
diagram of an i* model. The SR-diagram is much more comprehensive than 
its strategic dependency (SD) counterpart and encompasses all the dependency 
information that is captured in the SD-diagram. In fact, an SD-diagram rep¬ 
resents the dependencies between different actors but does not exactly depict 
which particular model element of the depender is dependent on which partic¬ 
ular model element of the dependee. The SR model is much more elaborate in 
this sense. 

3.1. The Naive Algorithm 

The simplest and most obvious solution to develop the set of all possible 
state transition models from an i* model, is to consider each model element 
separately and assume that they can exist in either of 3 possible states - Not 
Created (NC), Created Not Fulfilled (CNF), and Fulfilled (F) - and apply the 
brute-foree approach. In the first phase of this research, we assume a single 
instance of each model element appearing in the SR-diagram, i.e., each goal, 
task, or resource appearing in the SR-diagram represents a single instance of the 
corresponding model element. We obtain sequences of states or state transition 
models by evaluating the all possible permutations of the model elements and 
the state in which they exist. 
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Let us demonstrate the above concept with an example. Consider the sim¬ 
plest possible SR diagram with one actor consisting of only one goal G. This is 
shown in figure [^a. The goal G can be in either of three states - Not Created 
denoted by G, Created Not Fulfilled denoted by G, and Fulfilled denoted by G. 
These three states give rise to 3! state transition models as shown in figures [^b 
to Eg. 
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Figure 1: (a) Actor A with a single goal G; (b) — (g) Possible state transition models that 
can be derived by permuting the state space 

However, out all these 6 state transition models, only figure l.b is semanti¬ 
cally correct. All the other state transition models are semantically inconsistent 
as a model element can go through its possible states in exactly one possible 
sequence - NC (G) —)■ CNF (G) —)■ F (G). We call this sequence the default 
sequence, and must be satisfied by all model elements. Now, let us increase 
the complexity by incorporating one more model element in the SR-diagram, 
i.e., let there exist two model elements in the SR-diagram. These two model 
elements can belong to the same actor or to two different actors. In either case, 
the complexity analysis remains the same. 

Let Ai and A 2 be two different actors, each with a single goal node Gi and 
G 2 , respectively. Since each goal can be in either of 3 states, the total number 























of possible combined states is 3^ (= 9). However, since both Gi and must 
individually satisfy the default sequence, it is interesting to observe the valid 
state transition sequences that do not violate the individual default sequences. 
We draw a State Sequence Graph that maps all the possible state transition 
paths from the source node - denoted by (Gi G 2 ) - to the destination node - 
denoted by (Gi G' 2 ^. Figure [^b illustrates the State Sequence Graph for two 
model elements. 



Figure 2: (a) Actors A1 and A2 with goals GI and G2, respectively; (b) The State Sequence 
Graph over the set of 3^ = 9 possible states 

The State Sequence Graph has all the 9 possible combined state represen¬ 
tations as vertices. These vertices are connected in the form of a mesh as all 
state transitions do not satisfy the default sequence. Each path, in the State 
Sequence Graph, from the source node (Gi G 2 ) to the destination node (Gi 
G 2 ) defines a semantically valid set of state transitions. In other words, each 
path represents a state transition model. Thus, with two model elements, we 
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obtain 6 possible state transition models that satisfy the default sequences of 
the individual model elements. 

Definition: State Sequence Graph 

A State Sequence Graph, G, can be defined as a 2-tuple (V,E) where V 
represents the set of vertices and E represents a set of directed edges such that, 

1. Each state (Gi G2.... G„) S V is an 7r-tuple that represents each of the 
n involved model elements in either of 3 possible states NG, GNF, or F, 
denoted by the generic symbol Gk- 

2. Each directed edge e^- S E is directed from vertex Vi to vertex Vj such that 
Vi —> Vj satisfies the default sequence for any one of the n model elements 
represented in every vertex notation. This implies that Vi —>■ Vj represents 
either of the following - 

(a) Some goal Gi goes from the NG state to the GNF state, denoted by 
(Gi... G,....G„) ^ (Gi... G,....G„), or 

(b) Some goal Gi goes from the GNF state to the F state, denoted by 

(Gi... G,....G„) ^ (Gi... G,....G„) 

3. The number of vertices in the vertex set V is 3", i.e., |V|= 3" 

4. Each path from the source vertex (Gi G2 ... G„_i G„) to the sink vertex 
(Gi G2 ... Gn-i Gn) represents a valid state transition sequence that 
satisfies the default sequence of each individual model element Gi, G2, ..., 
Gn-i, Gn, i.e., every unique path (Gi G2 ... G„_i G„) —>■ .... —>■ (Gi G2 
... Gn-i Gn) represents a state transition model 

The next level of complexity involves 3 different model elements. The analy¬ 
sis remains the same irrespective of how these 3 model elements are distributed 
between actors. Let Gi, Gi and G3 be the three different goals plotted in the 
SR-diagram. As mentioned above, since each goal can be in either of 3 states, 
this particular situation will result in a state space with 3^(= 27) combined 
states. The State Sequence Graph obtained is shown in Figure [^b. 
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Figure 3: (a) Actors Ai, A 2 , and A 3 with goals Gi, G 2 , and G 3 , respectively; (b) The State 
Sequence Graph over the set of 3^ = 27 possible states 

A detailed reachability analysis using Depth-First Search yields 90 different 
paths that can be used to reach the sink vertex (Gi G 2 G 3 ) from the source 
vertex (Gi G2 G3). Each of these paths represents a plausible set of state 
transitions such that none of the 3 goals Gi, G 2 , and G 3 violate the default 
sequence. Thus, with 3 model elements in the SR-diagram we get 90 possible 
State Transition Models that correlate to the given i* model. 

3.1.1. Gounting Multi-dimensional Lattice Paths 

In general, it is interesting to observe the number of paths within a State 
Sequence Graph corresponding to an i* model with k model elements. It is 
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intuitive from the above case studies that the state space grows exponentially 
as a function f{k) = 3^. This is because each of the model elements can exist 
in either of 3 states. The growth function representing the growth of the state 
transition model space is far more complex. Before going into the details of an 
upper bound representing the growth of the state transition model space, we 
need to keep in mind that every model element is initially in the Not Created 
state and it needs 2 transitions to reach the Fulfilled state. Thus, the distance 
covered by each model element is always 2. 

Consider the case where k = 2. Since each model element needs to cover a 
distance of 2, we can consider {P 1 P 2 ) and {PiPi) as the Least Upper Bound and 
the Greatest Lower Bound of a 2 x 2 lattice. In general, the number of paths 
on a ni X 712 lattice is given by - 

(ni + 712 )! 


Lp = 


Til + 772 
77i 


So for a 2 X 2 lattice structure, we have - 

(2 + 2 )! 


Lp = 


2 + 2 
2 


77i!772! 


4! 


( 1 ) 


2 ! 2 ! 


= - =6 
2! 2! 4 


This is exactly what we obtain from our empirical study in Figure 

When fc = 3, we can represent the set of all possible transitions from 
{P1P2P3) to {P 1 P 1 P 3 ) as 3-dimensional cubic lattice. Again, since each model 
element makes 2 transitions to be fulfilled, hence, we obtain a 2 x 2 x 2 3- 
dimensional cubic lattice. In general, the number of paths in a 3-dimensional 
cubic lattice with dimensions ( 771 , 712 , 773 ) is given by - 

(771 + 772 + ^3)! 


Lp = 


77l + 772 + ns 
77i, 772, ns 


77i!772!773! 


( 2 ) 


So for a 3-dimensional cubic lattice with dimensions(2, 2, 2), we have 

(2 + 2 + 2)! 6! 720 


Lp = 


2 + 2 + 2 

2 , 2,2 


= 90. 


2 ! 2 ! 2 ! 2 ! 2 ! 2 ! 8 

Again, this is exactly what we obtain from our empirical study in Figure 

To generalize the upper bound on the growth function of the state transition 
model space, if we have a fc-dimensional hypercube lattice with dimensions ( 771 , 
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Table 1: Rate of growth of space w.r.t. the number of model elements 


No. of Process Elements 

State Space 

State Transition Model Space 

5 

243 

113400 

10 

59049 

2.37588E+15 

15 

14348907 

8.09487E+27 

20 

3486784401 

7.78117E+41 

25 

8.47289E+11 

9.06411E+56 

30 

2.05891E+14 

7.74952E+72 

35 

5.00315E+16 

3.48622E+89 

40 

1.21577E+19 

6.5092E+106 

45 

2.95431E+21 

4.2227E+124 

50 

7.17898E+23 

8.289E+142 

55 

1.74449E+26 

4.4083E+161 

60 

4.23912E+28 

5.8022E+180 

65 

1.03011E+31 

1.7528E+200 

70 

2.50316E+33 

1.1403E+220 

75 

6.08267E+35 

1.5123E+240 

80 

1.47809E+38 

3.8999E+260 

85 

3.59175E+40 

1.876E+281 


712, nu), then the number of paths is given by - 


Lp = 


Til + 712 + + nu 


(m + 712 + ... + Tlfe)! 


( 3 ) 


niW-.-nkl 

Irrespective of the number of model elements involved, since each model element 
travels a distance of 2 to become fulfilled, we have the condition ni=2. 

The total number of paths is given by - 


Lp = 


(Eti2)! 


(2fc)! 

2 k 


( 4 ) 


nr=i(2!) 

Equation can be used to generate a data set and observe how the state 
space and the state transition model space grows with increasing number of 


13 










model elements in the i* model. Table represents such a data set as the 
number of model elements increases from 5 to 85 in steps of 5. Data thus 
obtained can be plotted on a graph and the trends may be observed. Figure 
below depicts the rate of growth for both the state space and the state transition 
model space with respect to the number of model elements depicted in the given 
i* model. 


Rate of growth of space w.r.t. the number of 
process elements 

^^State Space ^^State Transition Model Space 
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Figure 4: Graph depicting the rate of growth of the state space and state transition model 
space with respect to the number of model elements in the i* model for the Naive Algorithm 
[To be reproduced in color on the Web and in black-and-white in print] 


Interpretation of the graph is quite interesting. Some of the more interesting 
observations are as follows: 

1. The reader should not to be misled by the linear nature of the growth 
curves. A careful analysis of the graph reveals that the vertical axis rep¬ 
resents a Logarithmic scale where the values represent exponentially in¬ 
creasing integers. The values range from 1 to 1.876A-|-281. Linear curves 
on a Logarithmic scale represent Exponential growth functions. In fact, 
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the state space growth function, as represented by the blue line, actually 
represents the growth function f{k) = 3^'. The growth function of the 
state transition model space, as represented by equation]^ is represented 
by the red line. 

2. Another significant observation here is that the gradient of the blue line 
is much less than that of the red line. This implies that although both 
the state space and the state transition model space grows exponentially, 
the rate of growth for the state transition model space is much higher 
compared to that of the state space. In fact, the values in Table reveal 
that, in every step, the state space grows by a factor of 10^ — 10^, whereas 
the state transition model space grows by an approximate factor of 10^® — 
10^°. This is really huge in terms of the rate of growth. 

We can conclude from the above data that the Naive Algorithm causes a 
hyperexponential explosion in the state transition model space. The growth 
curve of the state transition model space is so steep that it reaches infinitely 
large values for very small values of fc, the number of model elements in the i* 
model. It is evident from the nature of the curves that the state transition model 
space becomes quite unmanageable when we are looking at the i* model of an 
entire enterprise, comprising of hundreds of model elements. Thus, it becomes 
necessary to extract partial sequence information that remain embedded within 
an i* model and perform some pruning activities while the state transition model 
space is being generated. 

3.1.2. The Naive Algorithm: 

Input: SR-diagram of the i* model of an enterprise 

Output: The set of plausible state transition models that can be derived from 
the given i* model 

Data Structure: A List for each actor that stores model elements of the actor 

Step-1: Select the i-th model element Pi from the List of model elements for 
the actor Aj. 
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Step-2: Remove Pi from the List. 


Step-3: Pi can make two transition from P^-Not Created to P^-Created Not 
Fulfilled and from P^-Created Not Fulfilled to Pi-Fulfilled, in 
that order. 

Step-4: Generate all possible execution traces by interleaving the default se¬ 
quences of all model elements that have been removed from the List, such 
that, the default sequence of the individual model elements is satisfied. 

Step-5: Repeat Steps 1-4 for all model elements Pi residing within the Actor 
boundary, i.e., while the List is not empty. 

Step-6: Repeat Step 5 for all actors in the i* model. 

Step-7: Perform cartesian product between the sets of state transition models 
as obtained for individual actors, to generate the set of possible state 
transition models for the entire i* model. 

Step-8: Stop. 

3.2. The Semantic Implosion (SI) Algorithm 

The motive here is to prevent the hyperexponential explosion of the state 
transition model space that is caused by the Naive Algorithm. Although the 
Naive Algorithm generates all possible state transition models that can be de¬ 
rived from an i* model, some filtering can be done on this model space. The 
simplest means of doing this is to feed each possible model being generated 
into some standard Model Veriher like NuSMV and check the model against 
user-defined temporal compliance rules, specified using some standard temporal 
language like CTL or LTL. However, since this needs to be done on the entire 
state transition model space, the time complexity of the entire process becomes 
unmanageable even when machine-automated. 

The desirable situation here is to prevent the hyperexponential explosion from 
occurring in the first place. We propose the Semantic Implosion Algorithm, or 
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SIA, that tries to achieve this. SIA is based on the underlying hypothesis that 
although an i* model is sequence agnostic, there exists some embedded temporal 
information that can be extracted and exploited to reduce the plausible space of 
state transition models. Temporal compliance rules may be defined that further 
reduce the number of coherent state transition models. 

Every model element Pi residing within the SR-diagram of an actor is 
uniquely identified using a system variable Vi- Every system variable Vi can 
have either of three values - 0, 1, or 2 - representing the conditions Not Created 
(Pi), Created Not Eulfilled (Pi), and Eulfilled (Pi), respectively. Every time 
a new model element Pj is encountered, a corresponding system variable Vj 
is created and initialized to 0 representing the Not Created situation. This is 
reflected in the state transition model of the enterprise with a transition from 
the current state to a new state where the corresponding system variable Vj 
becomes a member of the state variables. 

The algorithm proceeds to explore the child model elements of a chosen 
parent model element. Before doing so, the corresponding system variable Vj 
is updated to contain the value 1 and pushed onto a stack. This is reflected in 
the state transition model with a state transition from the current state to a 
new state that reflects the fact that Pj has been created but not fulhlled. A 
model element is said to be fulfilled when either it has no child model element 
(we have reached the actor boundary) or all its child model elements have been 
individually fulfilled. When this happens, the system variable Vj corresponding 
to the parent model element Pj is popped from the stack and updated with the 
value 2. A corresponding state transition is incorporated in the state transition 
model that reflects the fact that model element Pj has been fulhlled. Figure 
illustrates the state transition model corresponding to a single model element 
and how the corresponding system variable is incorporated and updated along 
each transition. 

However, it is interesting to note how the child model elements of a partic¬ 
ular parent are processed. The processing differs for task decompositions and 
means-end decompositions. A task decomposition is an AND-decomposition and 
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Figure 5: (a) Actor Ai with goal Gi; (b) The corresponding State Transition Model 

demands that all the child model elements be fulfilled in order to declare that 
the parent has also been fulhlled. A means-end decomposition, on the other 
hand, is an OR-decomposition and provides alternate strategies to fulfill the 
parent model element. Let us elaborate on the consequences of these two de¬ 
compositions. 

A task decomposition requires that all the child model elements be fulfilled 
before changing the state of the parent model element to the fulfilled state. 
However, since an i* model is sequence agnostic, the child model elements may 
be fulfilled in any random permutation. System variables associated with the 
child model elements should not defy the default sequence defined in section 


of model elements (Pi, P 2 , ■■■, Pm)- The system variables associated with these 
model elements are Vi, V 2 , ..., Vm, respectively. We define a state transi¬ 
tion from the current state with Vj=l to a new state with the state variables 
Vj=l, y'fPn Vr=0. There exists several execution permutations of the decom¬ 
posed model elements that results in a state with the state variables, Vj=l, 
V(Ai, Vr=2. The set of all possible execution sequences can be defined using a 
lattice structure, similar to the ones shown in figures and Since all child 
model elements are fulfilled in this state (the GLB of the lattice), we define 
another state transition in the state transition model that reflects the fact that 
the parent model element is also fulfilled, i.e., the new state has state variables 
Vj=2, Vr=2. The state transition model corresponding to such a task 

decomposition is shown in figure 


3.1 Let a model element Pj be decomposed by a task decomposition to a set 
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Figure 6 : (a) Actor A\ with goals Gi, G 2 , cind G 3 connected through a task decomposition; 
(b) The corresponding set of all possible State Transition Models 

The interpretation of the figure is quite interesting. The lattice structure 
represents the set of all possible execution sequences that result in the successful 
fulfillment of the task decomposition. As seen in section [3T| the number of paths 
in a lattice structure for two model elements is 6. All of these 6 paths represent 
valid execution sequences or state transitions. Each path gives rise to a different 
state transition model. This implies that the task decomposition shown in figure 
gives rise to 6 possible state transition models. The Naive Algorithm^ on the 
other hand, would generate a lattice structure with three model elements and the 
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number of possible state transition models would become 90. This is a significant 
reduction in the state transition model space. In fact, the significant observation 
here is that a lattice structure will be generated only where AND-decompositions 
take place. In other words, only AND-decompositions will increase the size of 
the state transition model space. 

A means-end decomposition is easier to handle. OR-decompositions, in gen¬ 
eral, do not increase the size of the state transition model space. Rather, if a 
particular model element Pj decomposes via a means-end decomposition into k 
model elements {Pi, P 2 , ■■■, Pk), then we introduce k different transitions from 
the current state ( Vj=l) to k unique new states, each representing one of the k 
alternate means ( Vj=l, Vp=0, An OR-decomposition is characterized by 

the fact that fulfilling any one of the alternate means implies fulfilling the par¬ 
ent model element. Thus, each of these k new states will make two transitions 
(labelled by VpiO—and RpT—>■2, Vp^;^) to reach their respective fulfillment 
states. Each alternate means will have a separate fulfillment state labelled by 
Vj=l, Vp=2, Vp^]^. All the k fulfillment states will converge to a final state 
that represents the fulfillment of the parent model element Pj and is labelled 
by b(,=2, Vp^;^ Vp=2. The structure obtained is similar to the longitudinal lines 
on the globe of the earth. Figure [^illustrates this further. 

3.2.1. Some interesting Observations 

1. Decompositions can be nested. This implies that decompositions can occur 
within other decompositions. One particular decomposition link may be 
further blown up with a second decomposition. For instance, means-end 
decompositions may be followed by a task decomposition along one means- 
end link and a means-end decomposition along some other means-end link. 
Figure illustrates this scenario. This nesting of decompositions does 
not require any modifications on the algorithm. The corresponding state 
transition models are built accordingly where the state transition sub¬ 
model of the nested decomposition is mereologically connected to the state 
transition model of the outer level decomposition. 


20 




<G,Gj> <G,Gj> <G,G4> 



< G,> 

(b) 


Figure 7: (a) Actor Ai with goals Gi, G 2 , G 3 , and G 4 connected through a means-end 
decomposition; (b) The corresponding State Transition Model 

2. It is interesting to note what happens if we reach a model element Pi, 
located at the actor boundary of actor Ai, that is dependent on some 
model element Pj that is located at the actor boundary of actor Aj. In 
that case, we assume that the model element Pi will be fulfilled by Aj, 
pop out the system variable Vi from the stack and set its value to 2. At 
the same time we introduce a temporary transition in the corresponding 
state transition model that changes the state of Vi from Created Not 
Fulfilled(C7VF) to Fulfilled(F). This is necessary as we cannot proceed 
with the construction of the state transition model of individual actors 
without this assumption. However, we need to maintain a list of all such 
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Figure 8: The State Transition Model corresponding to a nested decomposition. An outer 
mean-end decomposition contains another means-end decomposition along the leftmost means 
and a task decomposition along the rightmost means. 


dependencies. A Global List is maintained that stores 2-tuples of the form 
{depender variable, dependee variable). Once the state transition models 
of the individual actors have been built, the elements of the Global List are 
accessed. Each element represents a dependency of the form {Vik, Vji) 
and is interpreted as model element Pk within actor Ai depending on actor 
Aj for model element Pi . The temporary transition in the state transition 
model of actor Ai representing the change 14 : 1 —>■ 2 is replaced by 
two new transitions that connect the state transition models of actors Ai 
(STMi) and Aj (STMj). The first transition is established from the state 
in STMi having label 14=1 to the state in STMj having label Vi=2. The 
second transition is placed from the state in STMj having label Vi=2 to 
the state in STMi having label 14=2. {Vik, Vji) is removed from the 
Global List. Figure [^further illustrates this process. 
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Figure 9: (a) Goal Gs of actor Ai dependant on Goal G 4 of actor A 2 ; (b) Temporary transi¬ 
tion from G 3 to G 3 introduced; (c)Resolution of the dependency by replacing the temporary 
transition with two permanent transitions 


3 . Dependency resolution causes state transitions to be set up between states 
belonging to the state transition models of the depender and the dependee. 
If the depender and dependee have M and N possible state transition 
models, respectively, then we get a maximum of M x N combinations 
for interlinking the state transition models of the depender and dependee. 
Every dependency resolution must take place simultaneously in all the 
M X N combinations. 

Let n be the total number of model elements occurring in the SR-diagram 
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of the enterprise. The terminating condition of the SI Algorithm is given by the 
constraint, Vj=2 and the Global Dependency List is empty. The algorithm 
initiates with the model elements at the actor boundaries that do not stem 
from a parent model element. State transitions are defined in the corresponding 
state transition model as and when model elements are discovered, explored and 
fulfilled. Let us look into the Semantic Implosion Algorithm now. 

3.2.2. The Semantic Implosion Algorithm: 

Input: SR-diagram of the i* model of an enterprise 

Output: The set of plausible state transition models that can be derived from 
the given i* model 

Data Structure: A Local Stack for each actor that stores model elements of the 
actor and a Global List to keep track of dependencies between actors 

Step-1: For every model element Pi that is not at the end of a task decomposi¬ 
tion or means-end link, assign a system variable Vi=0. Perform a Depth- 
First Scan of the SR-diagram of each actor starting at these boundary 
model elements. 

Step-2: For any model element Pj with Fj=0, set Vj=l and push it onto 
the Local Stack. Reflect this transition in the state transition model by 
plotting a transition from the Not Greated state to the Greated Not Fulfilled 
state. Label this transition FjiO—>1. 

Step-3: Discover all model elements {Pi, P 2 ,..., Pq) that stem from the ele¬ 
ment Pj and are connected to Pj with task decomposition or means-end 
links. For each such element Pk, initialize a system variable Vk such that 

vLi^fc=o- 

a) If Pj is at an actor boundary with no elements stemming from it and 
with no dependencies to other actors, pop Vj from the Stack and set 
Vj=2. Set up a corresponding transition in the state transition model 
from the Greated Not Fulfilled state to the Fulfilled state. Label this 
transition Vj:l—>-2. 
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b) If Pj is dependent on some other actor for fulfillment, then pop Vj 
and insert it into the Global List with value Vj=2. Insert a temporary 
transition between states Created Not Fulfilled and Fulfilled. No need 
to label this transition as it is a temporary transition. 

c) If Pj undergoes a task decomposition then we obtain several different 
state transition sub-models for the task decomposition by permuting 
the order of execution of the decomposed model elements. Each such 
permutation can be considered to be a valid state transition sub¬ 
model and can be attached to the overall state transition model to 
obtain a set of unique state transition models for the actor. 

d) If Pj undergoes a means-end decomposition then we obtain multiple 
transitions from the current node in the same state transition model. 
Each transition represents an alternate strategy and is triggered by 
the corresponding guard condition. All the alternate state transitions 
emanating from the parent model element must converge at a state 
that represents that the parent model element has been fulfilled. 

Step-4 ■ Repeat Steps 2-3 for all siblings of Pj in all the state transition models 
generated for actor Ai. 

Step-5: Repeat Step ^until the Local Stack is empty. This leaves us with the 
set of plausible state transition models of an actor Ai. 

Step-6: Repeat Steps 1-5 to extract all the possible state transition models of 
all the actors in the i* model. 

Step-7: Remove elements of the form (Vik, Nji) from the Global List. 

Step-8: Remove the temporary transitions corresponding to this dependency 
from all state transition models of actor Ai. 

Step-9: Insert transitions from the Pfc-Created Not Fulfilled state in all 
state transition models of actor Ai to the Pj-Fulfilled state in all state 
transition models of actor Aj. Label these transitions Efc:!—^l. 
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Step-10: Insert another set of transitions from the P;-Fulfilled state to the 
the Pfe-Fulfilled state in between all possible state transition models of 
actors Ai and Aj. Label these transitions 14:1—>■2. 

Step-11: Repeat Steps 7-10 until the Global List is empty and all the depen¬ 
dencies have been resolved. 

Step-12: Stop. 

4. Experimental Results 

Let us perform some analytics on comparing and contrasting the behavior of 
the Naive Algorithm and the Semantic Implosion Algorithm. The two metrics 
that are used for this analysis are the State Space S'ize(SSS) and the State 
Transition Model Space S'z 2 e(STMSS). However, since both algorithms share 
the concept of every model element going through 3 states, the SSS metric will 
be the same for both algorithms and is defined by f(k)=3^. The STMSS metric 
is far more crucial in contrasting the behavioral differences between the two 
algorithms. 

Figure clearly illustrates the hyper-exponential explosion caused by the 
Naive Algorithm in the state transition model space. This is mainly due to 
the fact that the Naive Algorithm considers all possible orderings of the model 
elements ensuring the default sequence of each individual model element. A 
careful understanding of the SI Algorithm reveals that, while the state transition 
model corresponding to every actor is being built, the state transition model 
space increases only when the following conditions hold: 

1. Whenever a Task Decomposition is encountered. Suppose a task is de¬ 
composed to k different model elements. Since an i* model is sequence 
agnostic, these k model elements can be executed in any order. The set of 
all possible execution traces is given by a fc-dimensional hypercube lattice 
with each dimension having distance 2. As discussed in section |3.1[ the 
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state transition model space increases by a factor of as given by equa¬ 
tion]^ This implies that if the state transition model space representing 
the set of all possible state transition models already has p models, a task 
decomposition into q model elements causes the number of state transition 
models to become In general, if the SR-diagram of an actor within 

the i* model has d task decompositions, and the number of possible alter¬ 
nate execution sequences generated by each of these task decompositions 
be given by #Seqi, #Seq 2 , ..., #Seqd, then state transition model space 
size is given by the following relation: 

d 

5 =n (s) 

i=l 

2. Whenever a dependency is being resolved. Dependency resolution needs 
to be done individually for every pair of models that can be extracted 
from the state transition model space of the depender and the dependee. 
If the state transition model spaces of actors Ai and Aj contain M and 
N models respectively, then irrespective of the number of dependencies 
between Ai and Aj , the state transition model space changes from M + N 
to M X N. Again, if actor Aj requires dependency resolution with actor 
Ak, and actor Ak has L state transition models, then the combined state 
transition model space has size L x M x N. 

3. Even if 2 actors A^. and A^ are not dependent on each other. Complete¬ 

ness demands that the state transition model space of the entire i* model 
considers all possible combinations of the state transition models of actors 
Ar and Ag. Let {51, S 2 , 5„} be the state transition model space sizes 

of the n actors participating in an i* model. Then the size of the state 
transition model space of the entire enterprise (S) is given by the following 
relation: 

n 

5=ns. (6) 

i=l 

Dependency Resolution and Completeness conditions are both represented 
using the Cartesian Product relation. So, behaviour analysis boils to two basic 
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steps. The first steps involves observing the growth of the state transition model 
space for each individual actor. Once this has been done for all the actors, the 
state transition model space for the entire enterprise is constructed. 

4.I. Actor Internal Analytics 

It is very difficult to predict the distribution of model elements of an i* 
model within the SR-diagrams of individual actors. Since this is the first step 
of behaviour analysis, we are concerned with the state transition model space 
growth of individual actors within an i* model. In order to generate a consistent 
data set, we assume a uniform distribution of model elements. We increase the 
number of model elements occurring within the SR-diagram of an actor in the 
i* model in steps of 5. Without loss of uniformity, we assume that for every 5 
model element within an actor, there exists a task decomposition of 4 elements. 

We know that the Naive Algorithm causes the state transition model space to 
grow according to equation|^ i.e., STMSSat = where fci is the number of 

model elements in the i* model. The Semantic Implosion Algorithm grows only 
on the basis of task decompositions. The number of possible execution sequences 
generated by a 4-element task decomposition is obtained by substituting k = A 
in equation|^ i.e., ^ = 2520. Since every 4-element task decomposition 

increases the state transition model space size by a factor of 2520, applying the 
Cartesian Product relation, we obtain the growth function of the SI Algorithm 
to be given by STMSSs = 2520^^, where k 2 is the number of 4-element task 
decompositions occurring within the SR-diagram of an actor. Table reflects 
such a data set. 

The graph plotted on the basis of this data is shown in Figure It is 
interesting to analyze the graph. The vertical axis is again a Logarithmic Scale 
of Integers. Straight lines in this plot represent exponential functions. The 
slopes of the straight lines are directly proportional to the rate of growth of 
the corresponding exponential function, i.e., greater the slope, the greater is the 
exponential rate of growth. The following observations can be concluded from 
the graph: 
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Table 2: Actor Internal Analytics 


No. of Process 

Elements (fci) 

No. of 4-element Task Naive Algorithm 

Decompositions (^ 2 ) STMSSat = 

SI Algorithm 

STMSSs = 2520*^" 

5 

1 

113400 

2520 

10 

2 

2.37588E-hl5 

6350400 

15 

3 

8.09487E-h27 

1.6E-hlO 

20 

4 

7.78117E-h41 

4.03E-hl3 

25 

5 

9.06411E-h56 

1.02E-hl7 

30 

6 

7.74952E-h72 

2.56E-h20 

35 

7 

3.48622E-h89 

6.45E-h23 

40 

8 

6.5092E-hl06 

1.63E-h27 

45 

9 

4.2227E-hl24 

4.1E-h30 

50 

10 

8.289E-hl42 

1.03E-h34 

55 

11 

4.4083E-hl61 

2.6E-h37 

60 

12 

5.8022E-hl80 

6.56E-h40 

65 

13 

1.7528E-h200 

1.65E-h44 

70 

14 

1.1403E-h220 

4.16E-h47 

75 

15 

1.5123E-h240 

1.05E-h51 

80 

16 

3.8999E-h260 

2.64E-h54 

85 

17 

1.876E-h281 

6.67E-h57 


1. The blue line depicts the growth of the state space and is consistent for 
both scenarios, given by 3*. As both algorithms have the underlying basis 
that every model element goes through 3 states, the state space growth 
remains the same. 

2. The green line depicts the behaviour of the Semantic Implosion Algorithm. 
It is to be noted that the blue and green lines are very close to one another. 
This implies that the exponential rate of growth of the state transition 
model space as governed by the SI Algorithm is almost the same as the 
exponential rate of growth of the state space. 
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Figure 10: Behaviour analysis with respect to the state transition model space of individual 
actors for the Naive Algorithm (STMSS-N) and the Semantic Implosion Algorithm (STMSS-S) 
as the number of model elements in the i* model varies [To be reproduced in color on the Web 
and in black-and-white in print] 


3. The red line depicts the exponential rate of growth for the Naive Algo¬ 
rithm. The slope of the red line is much greater than those of the green 
and blue lines. This represents the hyper-exponential explosion that is a 
characteristic of the Naive Algorithm. 

4. A closer look at the STMSS values in Table [2] reveals the fact that the 
STMSS metric increases by a factor of 10^® - 10®® for the Naive Algorithm 
whereas for the SI Algorithm the STMSS metric increases by a factor of 
10 ®. 

The conclusions from Tablej^and Figure [T0| clearly indicate that the Seman¬ 
tic Implosion Algorithm provides a huge improvement in the rate of growth of 
the state transition model space with respect to individual actors in comparison 
to the Naive Algorithm. 
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J^.2. Inter-Actor Analytics 

Actor Internal Analytics explore the growth of the state transition model 
space for each individual actor. Inter-Actor Analytics provides an insight into 
how Actor Internal Analytics impact the state transition model space growth 
rate of the entire i* model representing an enterprise. There are two events that 
impact Inter Actor Analytics as follows: 

1. Density of Actors participating in the i* model, and 

2. Distribution of Process Elements within the actors. 

Let us individually analyse how these two parameters effect the growth rate of 
the state transition model space. 


4 . 2 . 1 . Variation of Actor Density 

Let there be n actors participating in an i* model. Let the size of the state 
transition model spaces of the individual actors be given by S 2 , Sn, 
respectively. Assuming a uniform density of 5 model elements within individual 
actors, we try to evaluate the rate of growth of the state transition model space. 
Similar to the data in table we assume that every actor has a 4-element task 
decomposition. 

The Naive Algorithm affects the state transition model space by causing the 
space size to grow according to equation]^ Replacing k = 5, we get the state 
transition model space size of every actor as - 


(2.5)! 

25 


— = 113400. 
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Since all the n actors of the i* model have uniform distribution of model 
elements, the state transition model space size remains the same for all actors 
as given by equation]^ i.e., Si = Combining equationsandwe 

get the state transition model space size for the entire enterprise (Sat) as - 


s» = (^r 


(V 
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Table 3: Inter Actor Analytics obtained by varying Actor Density 


No. 

Naive Algorithm 

SI Algorithm 

of Actors(n) 

STMSSiv = = 5 

STMSSs = (2520)” 

5 

1.87528E-b25 

1.01626E-bl7 

10 

3.51666E-b50 

1.03277E-b34 

15 

6.59471E-b75 

1.04956E-b51 

20 

1.23669E-bl01 

1.06662E-b68 

25 

2.31914E-bl26 

1.08396E-b85 

30 

4.34902E-bl51 

1.10158E-bl02 

35 

8.15562E-bl76 

1.11949E-bll9 

40 

1.52940E-b202 

1.13768E-bl36 

45 

2.86805E-b227 

1.15618E-bl53 

50 

5.37840E-b252 

1.17497E-bl70 

55 

1.00860E-b278 

1.19407E-bl87 


The Semantic Implosion Algorithm^ on the other hand, causes the state 
transition model space of individual actors to grow only when task decomposi¬ 
tions are encountered. Since we assume a 4-element task decomposition to exist 
in each actor, the state transition model space size of all the actors remains 
constant and is given by replacing fc = 4 in equation 


Lp 


(2.4)! 

24 


8 ! 

16 


= 2520. 


Since Si = 2520, replacing this value in equation]^ the state transition 
model space size for the entire enterprise (Sg), as given by the SI Algorithm, is 


Ss = (2520)” (8) 

We restrict the number of model elements in each actor to 5 and increase the 
density of actors from 5 to 55 in steps of 5. Table represents such a data set. 
Figure shows the corresponding graph structure that is obtained by plotting 
this data. 
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Figure 11: Behaviour analysis with respect to the state transition model space of the entire en¬ 
terprise for the Naive Algorithm (STMSS-N) and the Semantic Implosion Algorithm (STMSS-S) 
as the density of actors in the i* model varies [To be reproduced in color on the Web and in 
black-and-white in print] 


Interpretation of the graph is quite intuitive. The blue line represents the 
growth function of the Naive Algorithm. In this case study, it represents the ex¬ 
ponential function (113400)". The red line, on the other hand, plots the growth 
function of the Semantic Implosion Algorithm and represents the exponential 
(2520)". With the vertical axis representing a Logarithmic scale of integers, the 
two functions are mapped as straight lines with different gradients. Obviously, 
the gradient of the blue line is greater than the gradient of the red line. This 
has the semantic interpretation that the Naive Algorithm increases the state 
transition model space more rapidly as compared to the Semantic Implosion 
Algorithm. 

4 . 2 . 2 . Variation of the Distribution of Process Elements 

In this particular case study, we fix the number of actors involved in the 
enterprise i* model to 5. Keeping the number of actors fixed, the distribution 
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Table 4: Inter Actor Analytics obtained by varying the Distribution of Process Elements 


No. of Process 

Elements (fci) 

Naive Algorithm 

SI Algorithm 

STMSS-N-(^f,})T 

STMSS-S-{^llf)^,k 2 -ki : 5 

5 

1.87528E-b25 

1.01626E-hl7 

10 

7.57046E-b76 

1.03277E-h34 

15 

3.47576E-hl39 

1.04956E-h51 

20 

2.85249E-h209 

1.06663E-h68 

25 

6.11823E-h284 

1.08399E-h85 


of model elements per actor is increased from 5 to 25 in steps of 5. Assuming 
uniformity across all the actors in the i* model, every actor generates it’s state 
transition model space with the same size. The space size changes with varying 
model element distribution density. Let the size of the state transition model 
spaces of the individual actors be given by Si, S 2 , ■■■, S 5 , respectively, for some 
model element distribution k. 

The Naive Algorithm combines equations and to give a function repre¬ 
senting the growth rate of the state transition model space as follows: 

e {5,10,15,20,25}. (9) 

The Semantic Implosion Algorithm expands the state transition model space 
for task decompositions only. Our underlying assumption that there exists a 4- 
element task decomposition for every group of 5 elements dictates the growth 
function of the state transition model space as follows: 

- 5, Vfci, e {5,10,15,20,25}. (10) 

The data generated from equations[^and[^is shown in Table]^ The number 
of actors have been fixed to be 5. Figure [^represents the graph corresponding 
to this data. 

The interpretation of the graph is quite similar to the previous graphs. The 
vertical axis represents a Logarithmic scale of integers. Both the exponential 
function given by equations and [T^ appear as straight lines. However, the 
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Figure 12: Behaviour analysis with respect to the state transition model space of the entire en¬ 
terprise for the Naive Algorithm (STMSS-N) and the Semantic Implosion Algorithm (STMSS-S) 
as the distribution of model elements within actors in the i* model varies [To be reproduced 
in color on the Web and in black-and-white in print] 


gradients of the two lines are widely different. This implies that the rate of 
growth of STMSS-N (represented by the blue line) is much greater than that of 
STMSS-S (represented by the red line). 


4-3. SIA Analytics 

The analytics provided in tables Hi and 1^ and the corresponding graphs 


shown in figures 11 and 12 all point in the same direction. The obvi¬ 
ous conclusion from these data sets is that the Semantic Implosion Algorithm 
provides a huge improvement over the more simple Naive Algorithm. The im¬ 
provement is in the context of space complexity and the SI Algorithm provides 
this improvement with a factor of 10^® — 10^®. 

Accepting the above conclusion triggers an urge to take an insight into the 
behaviour of the SI Algorithm when both the parameters - Actor Density and 
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Table 5: Inter Actor Analytics obtained by varying both Actor Density and Distribution of 
Process Elements for the SI Algorithm 


No.of Process 

Elements (fci) 


SI Algorithm 


STMSS-5 

STMSS-10 

STMSS-15 

5 

1.01626E-bl7 

1.03277E-b34 

1.04956E-b81 

10 

1.03277E-b34 

1.06662E-b68 

1.10158E-bl02 

15 

1.04956E-b51 

1.10157E-bl02 

1.15617E-bl53 

20 

1.06663E-b68 

1.13769E-bl36 

1.21349E-b204 

25 

1.08399E-b85 

1.17503E-bl70 

1.38069E-b255 


Property Element Distribution - are varied simultaneously. Table provides 
such a data set. The data are obtained by varying the distribution of model 
elements in individual actors from 5 per actor to 25 per actor, in steps of 5. The 
state transition model space size is obtained using the following equation: 

STMSS-A = = fci - 5 (11) 

The A in equation El represents the number of actors. /c 2 is obtained from 
fci as mentioned in the equation due to the assumption that we have a 4-element 
task decomposition for every group of 5 model elements. Maintaining the uni¬ 
formity of model element distribution across all the actors of an i* model, we 
obtain the data set for 5, 10, and 15 actors, given by STMSS-5, STMSS-10, and 
STMSS-15, respectively. The graph obtained from the data set in table is 
shown in figure [T^ 

The graph is fairly simple to analyze and interpret. The vertical axis is 
again a Logarithmic Scale. Each of the individual lines (blue, red, and green) 
are linear, representing exponential growth functions. The fact that the state 
transition model space size will increase with greater number of actors has al¬ 
ready been observed in figure El Hence, the higher positioning of the lines as 
the number of actors increases. It can also be concluded from figure that 
for a fixed actor density, the state transition model space size increases with 
increasing density of model elements. Hence, the positive gradient in each of 
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Figure 13: Behaviour analysis of the Semantic Implosion Algorithm (w.r.t. the state transition 
model space) as the distribution of model elements within actors and the actor density in the 
i* model are both varied [To be reproduced in color on the Web and in black-and-white in 
print] 


the three lines. 

The more important observation here is that the gradient of the lines in¬ 
creases with increasing actor density, i.e., the green line is more steep compared 
to the red line which, in turn, is steeper than the blue line. We already know 
that the gradient of the straight lines represents the rate of growth of the ex¬ 
ponential functions representing the growth of the respective state transition 
model spaces. This means that as the actor density increases, the state transi¬ 
tion model space increases even more rapidly. 


5. Conclusion 

Enterprise architects are aware of the need for temporal information to be 
captured by a modelling language. However, a requirement specification mod¬ 
elling paradigm like i* is essentially sequence agnostic and rightfully so. i* mod- 
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els are used to provide an abstract graphical overview of the enterprise to the 
customer so that he/she has a better understanding of the implications of the 
requirements as specified by him/her. The true essence of modelling does not 
reside in providing a graphical interface to the outside world; rather modelling 
can be exploited for ensuring the correctness of the enterprise being designed 
by checking the model against inconsistencies, incorrect assertions, counter¬ 
possibilities and different other types of anomalies. Formal Model Checking 
methods and tools exist to achieve this. A correct model can then be used to 
automate the generation of code snippets that help in the design and testing 
phases of the System Development Life Cycle. 

Enterprise designers are of the same opinion that both Model Checking and 
Automated Code Generation demand the existence of sequential information 
within the model. Model Checking tools, typically check a model against cer¬ 
tain temporal properties. The need to bridge the gap between i* models and 
any other business process model is evident. Although model transformations 
have existed in the industry for quite some time, no work has been done to de¬ 
rive sequential models from i* models. This paper first illustrates and presents 
a Naive Algorithm for extracting sequences from i* model constructs. Simu¬ 
lation results demonstrate how this causes a hyperexponential explosion in the 
state transition model space. The Semantic Implosion Algorithm provides an 
approach to counter this explosion. 

Detailed simulations have been done by applying both the algorithms to 
similar types of i* models and the results show that the Semantic Implosion 
Algorithm provides a significant improvement over the Naive Algorithm. Typi¬ 
cally, the state transition model space grows in the order of 10^° for the Naive 
Algorithm, whereas, for the Semantic Implosion Algorithm, the growth rate is 
restricted to the order of 10^. Although this may not be the best approach to 
extract a minimal set of plausible state transition models that can be derived 
from a given i* model, it definitely provides a significant improvement over the 
Naive Algorithm. 

The set of possible state transition models, that correspond to a given i* 
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model, can be further pruned by feeding them into a Model Checking tool like 
NuSMV and checking them against certain customer-specific temporal proper¬ 
ties or compliance rules. All models that generate counter-examples may be 
discarded. This is one of the biggest advantages of modelling an enterprise. 
Also, once the set of valid state transition models have been obtained, we can 
map them to BPMN models, Petri-Nets, or even UML models. This helps 
Enterprise Architects by allowing the automated generation of code snippets, 
thereby, reducing the efforts required to build the enterprise. Thus, once the 
requirements have been finalized and modelled by the architects, the develop¬ 
ment of the enterprise becomes fully automated, ensuring greater consistency 
and correctness and reducing the risks of failure. 
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